IMS（Information Management System）は、長い歴史を誇る製品である。1966年、アポロ計画におけるサターンVロケットやアポロ宇宙船の部品を管理する目的で開発されて以来、半世紀を経た今もミッションクリティカルな基幹業務を支え続けている。
IMSはz/OS上で稼働し、「IMS Tran saction Manager」によるトランザクション・サーバーとしての機能と、「IMS Database Manager」による階層型データモデルのデータベース・サーバーとしての機能を提供する。
IMSの世界には、IMS生成という製品固有の手続きがある。これはIMSに対しトランザクションや端末などの資源定義を追加・変更・削除する場合、あるいはパラメータ設定を変更する場合に行われるもので、IMS製品モジュールの一部を直接コンパイル／連携編集により変更する作業である。この工程は煩雑で計画停止を伴うため、24時間365日の連続稼働を阻害する要因となる。
これを避けるため、IMSではかねてから生成作業に代わる多彩な手段を提供している。そのなかには、固定化した既存の運用手順に埋もれて見過ごされている手段もある。
そこで本稿では、「IMS生成をなくす」「計画停止を避ける」という狙いで、IMSの新旧機能を紹介する。IMS生成はもはや、「避けて通れない手続き」ではないことを説明したい。
IMS生成の目的と課題
IMS生成の目的は、大きく5つに分けられる。
1. バッファサイズなどのパラメータ定義変更
2. 一部ユーザー出口の導入・削除・入れ替え
3. データベース定義、アプリケーション定義、トランザクション定義の追加・削除・変更
4. 静的端末定義の追加・削除・変更
5. 一部PTF適用の反映
1、2、4、5はIMS生成によって製品ライブラリー（SDFSRESL）に定義内容が導入される。また3は、資源定義ライブラリー（MODBLKS）に定義内容が導入される（図表1）。
IMS生成は、以下の手順で実行する（図表2）。
（1） 資源定義やパラメータ設定をIMS提供のマクロ（アセンブラ命令セット）でコーディングする。
（2） コーディングしたマクロをアセンブルし、IMSモジュール生成用のSTAGE2 JCLを取得する。
（3） STAGE2 JCLを実行し、カスタマイズ済みのIMSモジュールを取得する。
（4） STAGE2 JCLをSMP/Eに登録し、新しいIMSモジュール構成およびPTFレベルを管理する。
IMS生成により資源定義を実行する場合、たとえば端末定義を1つ追加するだけでも、毎回これだけの手順が必要になる。また、パラメータ設定がIMS生成マクロにコーディングされ、製品モジュールに組み込まれるため、設定値を調べるにはSTAGE1マクロ記述を調査する必要が生じる。
本番環境、テスト環境、生成環境など複数IMSを使用する場合は、IMSごとに生成済みモジュールと対応するマクロ記述を管理しなくてはならない。これらの作業負荷が、IMS生成の第1の課題である。
またIMS生成は製品モジュールを更新する作業なので、生成の種類によりIMS停止が必要になり、24時間365日の運用を阻害する要因になる。これがIMS生成の第2の課題である。
そこで、図表1に示す各種IMS生成作業ごとに、これら2つの課題に対する解決策を紹介しよう。
パラメータ定義変更への対応
IMS生成マクロの1つであるBUFPOOLSマクロは、スケジュール関連プールのバッファサイズを指定する。IMS生成によってこのサイズを積み増しする場合、前述した生成手順をたどることになる。ただしこれは、「IMS生成によって設定を変更するならば」の話である。
BUFPOOLSマクロの指定値はすべて、IMSの実行時パラメータで上書きできるようになっている。IMS制御領域の実行JCL内、もしくはIMS PROCLIBメンバーであるDFSPBxxx（xxxはサフィックス。制御領域実行JCL中、RGSUF=で指定）内の指定のみを書き換えれば、IMS生成を行わずにバッファ関連指定を変更できる。
このように、現在では実行時パラメータによって多くのマクロ定義を上書きできる。図表3に、V14時点でのIMS生成マクロとそれを上書きする実行時パラメータの対応を記載したので参考にしてほしい。
またIMSの進化の流れも、マクロによるパラメータ設定を削減する方向へ向かっている。V10でFPCTRLマクロが、V13でSECURITYマクロが廃止され、当該マクロで指定していた項目はすべて実行時パラメータへ移行する方針が示された。
今後もバージョンアップに伴って、生成マクロから実行時パラメータへの移行が進むと予想されるので、マクロが廃止されて慌てて調査することのないよう、早期に実行時パラメータへ移行することが望ましい。
ユーザー出口の変更への対応
一部のIMSユーザー出口はSECURITYマクロ内で宣言し、IMS生成によってIMSモジュールへの静的リンクにより組み込む必要があった。そのため、新規ユーザー出口の組み込みもユーザー出口の変更も、IMS生成とIMSの停止・再立ち上げが必要であった。
しかし前述したように、V13でSECURITYマクロは廃止された。それに伴い、下記のユーザー出口モジュールの生成による組み込みが不要となり、ユーザー・ライブラリーからの直接ロードが可能になっている。
・ サインオン／オフ・セキュリティ出口ルーチン（DFSCSGN0）
・ セキュリティ再検証出口ルーチン（DFSCTSE0）
・ トランザクション許可出口ルーチン（DFSCTRN0）
さらに有用な機能として、Type-2コマンドによるユーザー出口の動的変更がある。これはV11で追加された新機能で、DFSDFxxx PROCLIBメンバーのUSER_EXITSセクションに記述したユーザー出口タイプとモジュール名を用いて、IMSを停止することなくユーザー出口を動的に切り替える。
Type-2コマンド発行のためのCSL （Common Service Layer）環境をあらかじめ構成しておく必要があるが、IMSの停止・再始動を伴うことなく、ユーザー出口を動的に変更できる。
MODBLKS関連資源定義
変更への対応
従来、データベース定義やトランザクション定義といったオンラインシステムの使用する資源定義はマクロによって記述し、IMS生成によってMODBLKS資源として導入する必要があった。また、その反映はIMS停止時に行われることが多い。
しかしMODBLKS資源の更新は、以下のようにIMSを停止せずに実行できる。
まず、図表4の定義を更新する際には、MODBLKSレベルでのIMS生成を行う（IMSCTRLマクロ中SYSTEM＝パラメータでMODBLKSを指定）。この生成作業で書き換えられるのはステージング・ライブラリーのみであり、オンラインには影響しないため、IMSオンライン稼働中でも実行が可能である。
その手順は、以下のようになる。
最初にステージング・ライブラリーの内容を、オンライン変更コピー・ユーティリティ（DFSUOCU0）によって、オンラインの非活動系MODBLKSライブラリーへコピーする。
次に、/MODIFYコマンドによって、MODBLKS活動系／非活動系データセットを切り替え、資源定義の変更をオンラインへ反映できる。これはIMSの歴史上、最初期から存在する手順なのだが、既存運用に埋もれて忘れられているケースも見られるので、今一度採用を検討する価値がある。
そしてV10では、IMS生成を完全に不要とするMODBLKS関連資源の定義機能が登場した。DRD（Dynamic Resource Definition）と呼ばれるもので、MODBLKS資源をRDDS（Resource Definition Dataset）と呼ばれるデータセットに保管し、管理する。
DRD環境ではType-2コマンドによって資源定義を変更し、即座にオンラインに反映できる。またオンライン変更はライブラリー単位の入れ替えであるため、変更される資源と関係のないトランザクションも影響を受ける場合があるのに対し、DRD環境では変更・削除に関連しない資源はまったく影響を受けない。
DRD環境では、資源の作成・更新・削除はそれぞれType-2コマンドのCREATE、UPDATE、DELETEによって実行する。この変更はIMS制御領域の制御ブロックに直接反映され、システム・チェックポイント時にRDDSへ書き出せる。
DRD環境を利用するには、CSL環境が必要となる。DRD環境への資源のインポートはRDDSだけでなく、従来のMODBLKSライブラリーからも実行可能であり、これを利用して旧来の資源定義を保持したまま、DRD環境への移行が可能である。
端末関連資源定義の
変更への対応
IMS端末は、物理端末の種類を定義するTYPEマクロ、属性を定義するTERMINALマクロ、そして論理端末との関連づけを定義するNAMEマクロによって定義される。静的端末の追加・変更・削除を行う場合は、前述のマクロを更新してIMS生成を実施し、IMS停止時などにオンライン・データセット（SDFSRESL）へ変更を反映する必要がある。
この課題に対する解決策として、まずETO（拡張端末オプション）という有償フィーチャーが挙げられる。この導入により、IMS生成マクロでロードモジュールのなかに作られていた端末定義を、「ETOディスクリプター」と呼ばれるPROCLIBメンバーのテキストファイルに置き換えられる。端末構造およびユーザー構造は、端末のログオン時およびユーザーのサインオン時に、ETOディスクリプターに従って動的に設定される。
ETOディスクリプターでは、「デフォルト・ディスクリプター」と呼ばれる端末定義のひな型を作成しておける。これを活用することで、端末定義の追加のためにIMS生成を行うことなく、動的に端末を追加できる。
また、OTMA （Open Transaction Ma nager Access）と呼ばれるトランザクション送受信用インターフェースを用いることで、既存のIMSアプリケーションに手を加えることなく、従来のIMS端末経由と同様にWeb経由のIMSトランザクション処理が可能となる。
フロントエンドの更改を伴うため、SNA端末環境からの移行は大規模になるが、煩雑なIMS端末の定義から解放され、既存のアプリケーション資産を保持したまま、IMSトランザクションを外部から利用可能にする有効な手段となる（図表5）。
PTF適用の反映への対応
IMSに対し提供されるPTFの一部は、反映のためにIMS生成が必要になる。これは必須の作業であるが、反映作業に伴うシステム停止は、IMSplex化によって避けられる（図表6）。
IMSplexを構成する全IMSへの同時適用が必須になるPTFは原則として存在せず、ローリング・メンテナンスによってシステムを停止させずに順次適用が可能である。
またIMSplex構成下では、前述した実行時パラメータによるパラメータ変更や、ETOディスクリプターによる端末定義の変更もローリング・メンテナンス方式で実行できる。
ここまでIMS生成が必要な各シチュエーションに対して、「IMS生成をなくす」「計画停止を避ける」という切り口でソリューションを紹介してきた。
昔からサポートされている機能もあれば、近年追加された新機能もあり、忘れがちな小技もあれば、大掛かりなソリューションもありと、さまざまなアイデアを紹介した。これらのどれか1つでも、今以上に効率的にIMSを利用するきっかけになれば幸甚である。
著者｜杉本 篤
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
テクニカル・コンピテンシー 第一テクノロジー
ITスペシャリスト
著者プロフィール
2014年、日本IBM システムズ・エンジニアリング（株）へ入社。入社以来、IMSの技術支援を担当。IMSのバージョンアップ支援やIMS DBレプリケーション・ソリューション関連プロジェクトを中心に活動する傍ら、IMS新バージョン発表のたびに国内へ移行情報や新機能に関する情報を発信している。
［IS magazine No.15（2017年4月）掲載］
